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(57) Data network signals, methods and devices 
that are suitable for multiplexing payload data in a pack- 
et switched data network are disclosed. Payload asso- 
ciated with multiple packets is multiplexed into a single 
multiplexed packet. Each payload portion is identified 
by a mini-header within the multiplexed packet. Mapping 
information may also be transferred as part of such mul- 
tiplexed packets which include multiplexed payload da- 
ta. Preferably, the mapping information is used to form 
mapping tables within routers at edges of access net- 
works. The mapping tables may be used to establish a 
relationship between mini-headers and full headers. 
The mapping tables may be used to multiplex data from 
packets to form a multiplexed packet at an ingress rout- 
er, and demultiplex the multiplexed packet at an egress 
router. Conveniently, neither gateways nor out of band 
signalling are required. 
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Des ription 

[0001] The present invention relates to data networks, 
and more particularly to data network signals, methods 
and devices that are suitable for multiplexing payload s 
data in a packet switched data network. 
[0002] I n recent years, packet switched data networks 
have become heavily used and relied upon. The best 
known of such networks use the known Internet protocol 
("IP") as detailed in the Internet Engineering Task Force, 10 
Request for Comment ("RFC") 791, the contents of 
which are hereby incorporated by reference. Numerous 
protocols based on IP are used to carry a variety of pay- 
load data on IP compliant networks. These include the 
Uniform Datagram Protocol ("UDP") and the Real-Time is 
Protocol ("RTP") as detailed in RFCs 768 and 1889 : the 
contents of which are hereby incorporated by reference. 
[0003] All of these protocols utilize headers to identify 
packets and attributes of packets transported across the 
network. Such headers introduce overhead. For exam- 20 
pie, common IP telephony techniques as detailed in In- 
ternational Telephony Union ('ITU') Recommendation 
H.323, the contents of which are hereby incorporated 
by reference, rely on the RTP to transport payload voice 
data. RTP in turn relies on the UDP and the IP. Each 2s 
RTP/UDP/IP compliant voice packet typically includes 
a total of forty (40) bytes of overhead in the header. 
[0004] By contrast, modern voice compression tech- 
niques compress voice payload to lower and lower bit 
rates. ITU Recommendation G.723.1, the contents of 30 
which are hereby incorporated by reference, for exam- 
ple, compresses voice data to 5.3 kbps. This results in 
voice data that is typically packetized every thirty (30) 
ms, with each packet having a payload of twenty (20) 
bytes. Thus, using the RTP may result in payload occu- 35 
pying only one-third of each packet, with the remaining 
two-thirds of the packet dedicated to protocol overhead. 
Other packet based protocols similarly often use only 
ten (10) to twenty (20) bytes of data. 
[0005] It has been recognized that multiple voice 40 
streams are typically exchanged concurrently between 
two IP telephony gateways. Thus, voice payload for mul- 
tiple streams may be combined or multiplexed within 
packets reducing the overhead to payload data ratio for 
each packet. Proposals based on such multiplexing in- *s 
elude K. Tanigawa, T Hoshi and K. Tsukada: A RTP sim- 
ple multiplexing transfer method for Internet telephony 
gateway, IETF draft, work in progress June 1998; J. 
Rosenberg and H Schulzrinne: An RTP payload format 
for user multiplexing, IETF draft, work in progress, Aug. so 
21, 1998; and Mark Handley (ISI), AVT group meeting 
minutes for Aug. 1 998 meeting. 

[0006] These proposals suggest stripping existing 
RTP/UDP/IP h aders at n twork gat ways, mapping 
thes to mini-h aders included in multipl x d packets, ss 
and transferring the multiplex d packets including mini- 
headers in a single IP packet to a recipient gateway In 
advance of transferring multiplexed packets, the rela- 



tionship between RTP/UDP/IP headers and mini-head- 
ers is communicated between gateways, typically using 
out-of-band signalling. The recipient gateway replaces 
each received mini-header with an associated full RTP/ 
UDP/IP header and passes the reconstructed RTP 
packets to computing devices on the far side of the re- 
cipient gateway. 

[0007] These approaches rely on the presence of 
gateways, such as those defined in ITU Recommenda- 
tion H.323. Moreover, they typically require modifica- 
tions to control protocols to exchange mapping informa- 
tion between gateways. However, many IP telephony 
applications and similar low bit rate applications are 
end-to-end, and do not rely on gateways. 
[0008] Accordingly, an improved method of multiplex- 
ing data within packets, and a protocol making use of 
such a method are desirable. 

[0009] In accordance with the present invention, pay- 
load associated with multiple packets is multiplexed into 
a single multiplexed packet. Each payload portion is 
identified by a mini-header within the multiplexed pack- 
et. Advantageously, mapping information is also be 
transferred as part of such multiplexed packets which 
include multiplexed payload data. Preferably, the map- 
ping information is used to form mapping tables within 
routers at edges of access networks. The mapping ta- 
bles may be used to establish a relationship between 
mini-headers and full headers. The mapping tables may 
be used to multiplex data from packets to form a multi- 
plexed packet at an ingress router, and demultiplex the 
multiplexed packet at an egress router. Conveniently, 
neither gateways nor out of band signalling are required. 
[0010] In accordance with an aspect of the present in- 
vention, payload data contained in a plurality of packets 
to be passed by way of a network node within a packet 
switched data network, is multiplexed by associating 
with the payload portion of each packet a mini-header 
smaller than a header for the packet. A multiplexed 
packet including each payload portion and an associat- 
ed mini-header, and further including a mapping token, 
which establishes a relationship between a mini-header 
and a header for one of the packets, for which this rela- 
tionship is not known at the network node is constructed. 
[0011] In accordance with another aspect of the in- 
vention, a mapping table may be formed at a network 
node within a packet switched network. The mapping 
table maps mini-headers identifying multiplexed pay- 
load data from several packets within a multiplexed 
packet, to complete headers usable to transport payload 
on the network. An entry of the mapping table may be 
formed by receiving a packet including at least one pay- 
load data portion from one of the packets; a mini-header 
associated with the payload data portion; and a mapping 
token, indicative of a relationship b tw n th mini- 
head r and a complet header for transporting the data 
portion on th n twork. Th formed ntry within the ta- 
ble, includes a portion of the mini-header and informa- 
tion derived from the mapping token, indicative of the a 
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r lationship betwe n the mini-header and the complete 
header. 

[0012] In accordance with another aspect of the in- 
vention, a computer data signal embodied in a carrier 
wave includes at least one payload data portion from a 
packet transportable within the packet switched data 
network. The data signal further includes a mini header 
associated with the payload data portion; and a mapping 
token, indicative of a relationship between the mini- 
header and the complete header for routing the packet 
on the network. 

[001 3] In accordance with yet a further aspect of the 
invention, a computing apparatus interconnected with a 
packet switched data network, includes computer read- 
able memory that stores a mapping table for mapping 
mini-headers identifying multiplexed payload data from 
several packets within a multiplexed packet to a com- 
plete header usable within the packet switched data net- 
work. As well, the computer readable memory stores 
computer readable instructions, that adapt the appara- 
tus to process multiplexed packets including, payload 
portions; mini-headers associated with each payload 
portion, usable in conjunction with the mapping table to 
construct a packet including the associated payload that 
may be transported on the packet switched data net- 
work; and at least one mapping token, usable by the ap- 
paratus to update the mapping table. Preferably the 
computing apparatus includes a router on the network. 
[0014] In accordance with another aspect of the in- 
vention, a computer readable memory stores computer 
executable instructions, that may be executed by a com- 
puting device interconnected with a packet switched 
network. The computer readable instructions adapt a 
computing device to maintain a mapping table for map- 
ping mini-headers identifying multiplexed payload data 
from several packets within a multiplexed packet to a 
complete header usable within the network. Moreover, 
they adapt the computing device to process a multi- 
plexed packet which includes a payload portion, formed 
from a packet transported on the network; a mapping 
header associated with the payload portion within the 
multiplexed packet and usable by the computing device 
in conjunction with the mapping table to construct a 
packet including the associated payload that may be 
transported on the network; and mapping information, 
usable by the device to update the mapping table. 
[001 5] In accordance with yet another embodiment of 
the invention, payload data contained in a plurality of 
packets to be passed by way of a network node in a 
switched packet network, is multiplexed, by searching 
a table with information in a header of each packet for 
a match. If a match for a given packet is not found, in- 
formation from its header is entered in the table in as- 
sociation with information for a mini-h ad r. A mapping 
token associating th given head r information with the 
mini-head r is also cr at d. The payload portion of the 
packet is extracted and the h ader is discarded. The 
mini-header is associated with the payload portion, and 



a multipl xed packet including the mapping tok n is 
constructed. 

[0016] According to a further aspect of the present in- 
vention there is provided a computer program element 

5 comprising computer program code means to make a 
computing apparatus execute procedure to perform the 
method described above. Additionally, this computer 
program element may be embodied on a computer 
readable medium. 

10 [0017] Other aspects and features of the present in- 
vention will become apparent to those of ordinary skill 
in the art, upon review of the following description of spe- 
cific embodiments of the invention in conjunction with 
the accompanying figures. 

is [001 8] Exemplary embodiments of the present inven- 
tion will now be described with reference to the accom- 
panying drawings, in which: 

FIG. 1 illustrates a computing network, including 
20 routers, that can support the various underlying in- 
ventive concepts of the preferred embodiment of 
the present invention; 

FIG. 2 is a block diagram of an exemplary architec- 
ture of routers of FIG. 1 ; 
25 FIG. 3 is a block diagram of an exemplary memory 
organization of routers of FIG. 1 ; 
FIG. 4 illustrates an example ingress mapping table 
formed at a router of FIG. 1; 

FIG. 5 illustrates an example egress mapping table 
30 formed at a router of FIG. 1 ; 

FIG. 6 illustrates an exemplary format of a multi- 
plexed packet; 

FIG. 7 illustrates an example format of a mini-head- 
er used in the packet of FIG. 6; 
35 FIG. 8 illustrates an example format of a mapping 
establishment token used in the packet of FIG. 6; 
FIG. 9 is a flow chart of steps performed at an in- 
gress router, and 

FIGS. 10 and 11 illustrate steps performed at an 
40 egress router. 

[0019] FIG. 1 illustrates a packet switched data net- 
work 10, including a backbone network 12, in commu- 
nication with access networks -A" and "B" 1 8 and 20, by 

45 way of access routers "A" and "B" 1 4 and 1 6, exemplary 
of embodiments of the present invention. Example com- 
puting devices A1 and A2 22 and 24 are in communica- 
tion with access network "A" 18; similarly example com- 
puting devices B1 and B2 26 and 28 are in communica- 

50 tion with access network "B" 20. 

[0020] Computing devices 22, 24, 26, 2B may be gen- 
eral purpose computing devices including a processor, 
memory and network interface (all not illustrated). The 
m mory may stor software including op rating syst m 

55 softwar and application software, which in turn may in- 
clude an IP stack. Th application software may include 
ITU Recommendation H.323 compliant client software, 
allowing computing devices 22, 24, 26 and 28 to estab- 
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lish end-to-end voice over IP t lephony sessions with 
each other. 

[0021] Backbone network 1 2 is preferably an IP com- 
pliant data network in accordance with RFC 791 , includ- 
ing conventional packet routers 30 and 32. Backbone 
network 12 could, for example, be the public Internet. 
Access networks "A" and "B" 18 and 20 are similarly IP 
compliant data networks. These may be corporate in- 
tranets, or simply portions of the public Internet. Access 
routers "A" and "B" 14 and 16 interconnect access net- 
works "A" and B B" 18 and 20 with backbone network 1 2, 
respectively. As illustrated, access routers 14 and 16 are 
in direct communication with routers 30 and 32 of back- 
bone network 12. Routers 14, 16, 30 and 32 are thus 
nodes within network 10. Access routers "A" and "B" 14 
and 16 may, for example, be conventional Nortel Net- 
works Passport switches/routers adapted to function in 
manners exemplary of the present invention. 
[0022] As will become apparent, access routers "A* 
and ■B" 14 and 16 switch packets received from the re- 
mainder of access network "A* and m B m to backbone net- 
work 12. Similarly, access routers 14 and 16 switch 
packets received from backbone network 12 to access 
n tworks 'A' and "B". As well, access routers "A" and 
■B 1 1 4 and 1 6 multiplex, and optionally demultiplex, suit- 
able packets in manners exemplary of the present in- 
v ntion. 

[0023] An example hardware architecture of access 
router "A" 14 is illustrated in block diagram in FIG 2. The 
architecture of routers 16, 30 and 32 may be substan- 
tially similar to that of access router 'A' 14. As illustrated 
in FIGS. 1 and 2, access router "A" may include a proc- 
essor 34, in communication with storage memory 36 
and a plurality of input/output ("I/O") ports 38. I/O ports 
38 interconnect router 14 with the remainder of access 
network "A" and with routers of backbone network 12 
(FIG. 1). I/O ports may be conventional DS1; OC-3; 
Ethernet or other suitable interfaces. Storage memory 
36 may be any suitable combination of random access 
memory; disk memory; read-only memory; or any other 
suitable computing memory known to those of ordinary 
skill in the art. Processor 34, in turn, may be a conven- 
tional microprocessor such as an INTEL x86 processor 
or a Motorola MC68xxxx processor. Of course any other 
suitable processor may be used as part of router "A" 1 4. 
[0024] An example organization of memory 36 is illus- 
trated in FIG. 3. As illustrated, memory 36 stores an op- 
erating system 40; application software 42; a routing ta- 
ble 44; an ingress mapping table 46; and an egress 
mapping table 48. Operating system 40 in combination 
with application software 42 allow access router "A" 14 
to route packets in a conventional manner, as well as 
perform in accordance with methods exemplary of the 
present invention. 

[0025] Routing table 44 is form d by application soft- 
ware 42, and allows router 1 4 to route packets from one 
of I/O ports 38 to another based on a packet's destina- 
tion address. Routing table 44 may, for example, be 



form d at rout r 'A' 1 4 using the OSPF routing protocol, 
as detailed in RFC 2328, the content of which are hereby 
incorporated by reference, implemented by a portion of 
application software 42. Ingress mapping table 46 and 
s egress mapping table 48 are also formed by application 
software 42 in manners exemplary of the present inven- 
tion, and as detailed below. 

[0026] Ingress mapping table 46 establishes a one- 
to-one mapping of source IP address, destination IP ad- 

10 dress, and ports to mini-headers, to allow multiplexing 
of suitable packets originating with access network "A" 
18, prior to entering backbone network 12. That is, the 
payload of any packet of suitable length originating with 
a particular source IP address within access network "A" 

is destined for a particular destination address is associ- 
ated with a mini-header. An organization of ingress map- 
ping table 46 is illustrated in FIG. 4. As illustrated, along 
with each IP source address to destination address (in- 
cluding logical port number), as stored in fields 50 and 

20 52 of ingress mapping table 46, a payload type ("PT") 
field 54; an ingress router port number ("I Router Port*") 
field 56; and egress router fERouter") IP address and 
port number field 58; a channel identifier ("CID - ) field 
60; and a last-time refreshed ("LTR') field 62 are stored 

25 within ingress mapping table 46. As should be appreci- 
ated, each IP source address to destination address (in- 
cluding logical port number), as stored in fields 50 and 
52 may correspond to a single IP telephony connection 
across network 1 0. This connection is thus associated 

30 with a channel identifier stored in field 60. 

[0027] An example organization of egress mapping 
table 48 is illustrated in FIG. 5. Egress mapping table 
48 similarly establishes a one-to-one mapping of mini- 
headers to source IP address; destination IP address 

35 and ports, to demultiplex multiplexed packets received 
at router "A", exiting from backbone network 12. As il- 
lustrated, for each channel ID field 70, egress mapping 
table 48 stores an ingress router IP address and port 
number in field 72; an egress router port number in field 

40 74; a full RTP/UDP/IP header infield 76; a payload type 
in field 78; a last time refreshed in field 80; and a last 
packet reproduced timestamp and sequence number in 
field 82. 

[0028] Router "B" 16 acting as an egress or ingress 
45 router similarly forms egress and ingress mapping ta- 
bles of the form of ingress an egress mapping tables 46 
and 48. Conventional routers 30 and 32 will typically not 
form similar egress and ingress mapping tables. 
[0029] Router "A" 1 4 acting as an ingress router forms 
so |p packets containing payload data associated with mul- 
tiple RTP packets, to form multiplexed packets having 
the format of multiplexed packet 90 as illustrated in FIG. 
6. As illustrated, a multiplexed packet 90 includes a con- 
ventional UPD/IP head r 91 followed by a plurality of 
55 payload portions 92a, 92b and 92c, each associat d 
with a mini-header 94a, 94b and 94c. Each mini-header/ 
payload portion may be considered a channel within 
multiplexed packet 90. Further, some mini-header/pay- 
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load combinations such as mini-h ader/payload of 
fields 92c and 94c may further be associated with a 
mapping establishment token 96. It will be appreciated 
that multiplexed packet 90 may have significantly more 
or less than three multiplexed payfoad fields, as illus- 
trated. 

[0030] The format of each mini-header 94a, 94b and 
94c (collectively and individual mini-header 94) is illus- 
trated in FIG. 7. As illustrated each mini-header prefer- 
ably includes an eight bit channel identifier field 98 and 
a further eight bit pay load length field 100. Optionally, 
each mini-header 94 may additionally include an RTP 
time stamp and sequence number taken from the orig- 
inal RTP/UDP/IP header associated with the payload 
data. 

[0031] The format of each mapping establishment to- 
ken is illustrated in FIG. 8. As illustrated, each mapping 
establishment token includes an channel identifier field 
102; a payload length field, indicating a length of zero 
(0) 104; and a full RTP/UDP/IP header in field 106. 
[0032] In operation, a computing device : such as 
computing device A1 22 on access network "A" 18 illus- 
trated in FIG. 1 wishes to exchange packets each having 
a relatively small payload with a computing device B1 
26 on access network "B" 20. For example, computing 
device A1 22 may include an Internet telephony appli- 
cation that is compliant with H.323. As such, computing 
device A1 22 may form packets having a payload of 
twenty (20) bytes with an associated RTP/UDP/IP head- 
r. The RTP/UDP/IP header identifies computing device 
B1 26 on access network "B" 20, as well as an appro- 
priate logical port of device B1 26. At the same time, 
computing device A2 24 may wish to exchange similar 
small payload packets with computing device B2 28. 
[0033] Consequently, RTP/UDP/I P compliant packets 
originating with devices A1 and A2 22 and 24, identifying 
devices B1 and B2 26 and 28 are forwarded to access 
router "A" 14, which acts as an ingress router to back- 
bone network 1 2. The steps S900 performed by access 
router "A" 14 under control of software 42 may be better 
understood with reference to FIG. 9. Specifically, access 
router "A" 14 receives an RTP/UDP/IP packet in step 
S902 and determines if the received packet has "small" 
payload by, for example, examining the RTP/UDP/IP 
header associated with the received packet in step 
S904. In the preferred embodiment only payload data 
associated with packets having less than 256 bytes of 
payload will be multiplexed. However, packets with 
smaller or larger payload could be multiplexed. If the re- 
ceived packet is above this threshold size, it is passed 
to backbone network 1 2 in step S906, without being mul- 
tiplexed or otherwise modified. 

[0034] Next, for a "small" payload packet, access 
rout r "A" 14 examines source and destination packet 
addr ss s and ports for the RTP/UDP/IP packet, and 
ingress mapping tabl 46 stored in m mory 36 in step 
S906. If any of the ntries in fields 50 and 52 of ingress 
mapping table 46 (FIG. 4) correspond to the source and 



destination address s and ports of the RTP/UDP/IP 
header, access router 14 associates the channel 
number within field 60 to form a mini-header associated 
with the RTP/UDP/IP payload having the format of mini- 
s header 94 of FIG. 7, in step S910. Length field 100 is 
filled with the payload length of the RDP/UDP/IP packet 
derived from this RDP/UDP/IP header. Access router 
"A" 14 determines an IP address and port of a destina- 
tion egress router for the payload data from field 58. In 
10 the preferred embodiment, multiplexed packets des- 
tined for a particular egress router will be destined for a 
unique IP address and port at the egress router, dedi- 
cated to the receipt of multiplexed packets and stored 
within field 58. Router "A" then forms a multiplexed 

is packet destined for the destination egress router includ- 
ing the formed mini-header/payload combination. Ac- 
cess router "A" 14 also discards the full RTP/UDP/IP 
header associated with the payload. Preferably, access 
router "A" 14 will buffer each multiplexed packet for at 

20 least five milliseconds, and preferably no more than ten 
milliseconds. However, it may buffer the multiplexed 
packet for more or less time. An ideal buffer time may 
be experimentally determined. Alternatively, if a multi- 
plexed packet destined for the identified egress router 

25 is already buffered, router "A" may append the formed 
mini-header/payload combination to an already buff- 
ered packet. If within the buffering interval, additional 
RTP/UDP/I P packets arrive, such as a packet from com- 
puting device A2 24, and a similar mini-header is 

30 formed, destined for the same egress router, access 
router "A" 14 forms a multiplexed packet as illustrated 
in FIG. 6, containing the first and subsequent mini-head- 
ers and payload. 15 
[0035] The multiplexed packet is then forwarded to 

35 router 30 of backbone network 12, in a conventional 
manner, and is then eventually routed to its destination 
by way of router 32 and access router "B" 16 to an as- 
sociated logical port. Router "B" uses it egress table 48 
including channel ID entries to reconstitute a full header, 

40 as explained more fully below. 

[0036] If, on the other hand, table 46 of access router 
"A" acting as an ingress router does not contain an entry 
corresponding to a received RTP/UDP/IP header re- 
ceived from computing device A1 22, access router "A" 

45 14 initiates a query to an access router, such as access 
router "B" 16, associated with the RTP/UDP/IP destina- 
tion address to determine whether the egress router 
supports a multiplexing protocol in steps S914 and 
S916. The query may be initiated by way of UDP mes- 

50 sage to router "B" 1 6, or in any other way known to those 
of ordinary skill in the art. As will be appreciated by those 
of ordinary skill, a destination access router "B" 16 as- 
sociated with a destination IP address may be identified 
in step S914 at acc ss router "A" using routing table 44. 

55 [0037] If access router "B 1 does not respond to the 
query, or r sponds negativ ly as determin d in step 
S918, the RTP/UDP/IP packet is dispatched from ac- 
cess router "A" 14 in a conventional manner, as in step 
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S906, without multiplexing or modification. If acc ss 
router "B" 16 responds affirmatively, access router "A" 
creates a new entry in table 46 associated with the 
source and destination IP address pair and assigns a 
new channel ID in field 60 to the source/destination pair s 
in step S920. Next, access router "A* 14 forms a map- 
ping establishment token having the format of token 
102, in FIG. 8 including the assigned channel ID and 
RTP/UDP/IP header of the received packet. Thereafter, 
the mapping establishment token, is included in the mul- 10 
tiplexed packet in step S922. Next, access router "A" 
forms a mini-header for the payload data, as illustrated 
in FIG. 7 in step S91 0 and includes the mini-header/pay- 
load for the received packet in the multiplexed packet, 
as in step S910. Preferably, the mapping establishment is 
token precedes the mini-header/pay load combination 
within the multiplexed packet as illustrated in FIG. 6. 
Within a multiplexed packet 90, a mapping establish- 
ment token can be distinguished from a mini-header by 
way of the contents of length field 104. For a mapping 20 
establishment token 96, length field 104 will indicate a 
length of zero (0). For a mini-header, having the format 
of mini-header 94, the equivalent field 100 will indicate 
a non-zero length. Alternatively, the length of the CID 
field of mini header 94 could be reduced to seven bits, 2S 
allowing the last bit to be used to identify a mapping to- 
k n. 

[0038] At the end of the buffer interval for the multi- 
plexed packet, the multiplexed packet is dispatched by 
access router "A" 14 in a conventional manner. As 30 
should be apparent, the UDP/IP header 91 of the mul- 
tiplexed packet identifies access router "A" as its source, 
and access router "B" as its destination. The multiplexed 
packet is routed across backbone network 12 to its 
eventual destination address identifying router "B" 16. 35 
[0039] Conveniently, then, with a proper choice of a 
buffering interval, payload associated with multiple 
RTP/UDP/IP packets associated with multiple IP con- 
nections between access network "A" and access net- 
work "B" will be combined and multiplexed in each mul- 40 
tiplexed packet. Moreover, as mapping establishment 
tokens are contained within the multiplexed packets, no 
out of band signalling is required. As such, this multi- 
plexing is compatible with existing protocols, such as 
those defined by ITU Recommendation H.323, without *s 
any required modification. 

[0040] Steps S1 000 and S1 1 00 performed by access 
router "B" 16 upon receipt of a packet, including a mul- 
tiplexed packet originating with access router *A" 14, 
may be better understood with reference to FIGS. 10 so 
and 11 . That is, router "B" upon receipt of any packet in 
st p S1002 determines rf it is directed to the known log- 
ical port and IP address reserved for multiplexed pack- 
ets in step S1004. If not, th packet is processed in a 
conventional manner in st p S1006. That is, th pack t ss 
may b passed to a further n twork interconnected de- 
vic without additional processing at access router "B" 
16. 



[0041] If the packet id ntifi s th IP address and port 
reserved for multiplexed packets, router "B" demulti- 
plexes the received packet in accordance with steps 
S1100 illustrated in FIG. 11. That is, router 'B' 16 se- 
quentially examines the contents of the received packet 
having the format of packet 90 to locate a mini-header 
94 or a mapping establishment token 96. If router "B" 
initially locates a mapping establishment token in step 
S1 1 02, it uses the contents of this header to update the 
contents of its egress mapping table, having the format 
of egress mapping table 48, as illustrated in FIG. 5. That 
is, as it encounters mapping establishment token, it cre- 
ates a new entry within its egress mapping table includ- 
ing the RTP/UDP/IP header. The channel ID field 102 
of the mapping establishment token may be used to 
complete field 70 of this entry. The contents of the RTP/ 
UDP/IP header may be used to complete the payload 
type field 78; ingress router IP address and port field 72; 
and RTP/UDP/IP header field 76 of the entry. As will be 
appreciated, the next RTP/UDP/IP packet associated 
with the recently stored mini-header may now be iden- 
tified using the channel ID now stored at access routers 
"A" and'B" 14 and 16. 

[0042] Once a mini-header is encountered within the 
received packet, access router "B m 16 under control of 
application software 42 extracts the mini-header in step 
S1 1 06 to associate a full RTP/UDP/IP header, as stored 
in field 76 of egress mapping table 48 with each payload 
portion of the multiplexed packet, to reconstruct a full 
RTP/UDP/IP packet. 

[0043] If the mini-header includes a timestamp and 
sequence number, these are used to reconstruct the 
RTP/UDP/IP sequence number and timestamp. Alter- 
natively, the contents of field 82 may be used to recon- 
struct suitable sequence numbers and timestamps. 
Specifically, upon creation of an entry reflective of a par- 
ticular source and destination IP address pair, field 82 
may be filled using the sequence number and time 
stamps of the received RTP/UDP/IP header. Thereafter, 
field 82 may be incremented appropriately each time a 
mini header associated with the same channel ID is re- 
ceived. The timestamp may be incremented using the 
local timer of router "B" 16. 

[0044] The resulting reconstructed RTP/UDP/IP 
packet is then forwarded by router "B" 16 to a proper 
destination computing device, such as devices B1 and 
B2 26 and 28 interconnected with access network "B', 
in step S1112. Steps S1102 and onward are repeated 
until the entire packet is processed. 
[0045] As mapping establishment tokens are included 
in packets in advance of mini-headers defined by the 
tokens, mini-headers for which an entry does not exist 
within egress mapping 48 should not be encountered. 
How v r, if a pack t including a mini-h ader for which 
an entry does not exist is encount red, the mini-head r 
and associated data is discarded. Moreover, full RTP/ 
UDP/IP headers need not b sent once suitable map- 
ping table entries are established. 
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[0046] Conv ni nlly, access routers "A" and "B" 14 
and 16 may also update the last time refreshed ("LTR") 
field 80,62 of egress mapping table 48, and ingress 
mapping table 46 any time a defined channel identifier 
is re-used. As well, periodically, at pre-determined inter- 
vals routers "A" and "B" may "flush" ingress and egress 
tables, deleting any entries that have not been used for 
a defined period, as determined with reference to the 
last time refresh field 62 and 80. This way, assigned 
channel identification numbers may be reused. This is 
particularly convenient as only eight bits are assigned 
to the channel identification header. Unique channel 
identification numbers may thus be re-used over time. 
In the context of IP telephony, and with an appropriate 
choice of refresh intervals, ingress and egress mapping 
tables may thus be representative of established and 
active calls. 

[0047] While in the above described embodiment, 
multiplexing and demultiplexing are performed at ac- 
cess routers "A" 14 and access router "B" 16, a person 
skilled in the art will appreciate that such multiplexing 
and demultiplexing, and maintenance of mapping tables 
could easily be performed at other network nodes, pref- 
rably at the "edge" of access networks "A" and "B B . For 
xample, routers 30 and 32 could be used to multiplex 
and demultiplex multiplexed packets. Moreover, while 
the invention is particularly well suited for use with IP 
t lephony data, it will be appreciated that the invention 
may be used in association with other types of data, and 
will typically provide benefits when overhead to pay load 
ratio is large. The network with which it may be used, 
need not conform to the IP, but may conform to succes- 
sors of this protocol or some other packet switched pro- 
tocol 

[0048] While the organization of software blocks, 
steps, payload data and header structures have been 
illustrated as clearly delineated, a person skilled in the 
art will appreciate that the delineation between blocks 
and structures is somewhat arbitrary. For example, soft- 
ware used to route, multiplex and demultiplex could be 
formed in hardware. Numerous other arrangements of 
software blocks and structures are possible. 
[0049] Finally, it will be understood that the described 
embodiments are intended to be illustrative, and in no 
way limiting. The embodiment are susceptible to modi- 
fication of form, arrangement of parts, steps, details and 
order of operation. 
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associating with a payload portion of each 
packet a mini-header small r than a header for 
said each packet; 

constructing a multiplexed packet comprising 
said payload portion for each packet and an as- 
sociated mini-header; 

including within said multiplexed packet a map- 
ping token, which establishes a relationship be- 
tween a mini-header and a header for one of 
said packets, for which said relationship be- 
tween a mini-header and header is not known 
at said network node. 

2. The method of claim 1 , further comprising including 
within said multiplexed packet a mapping token, es- 
tablishing a relationship between a mini-header and 
one of said packets, for all mini-headers for which 
said relationship between a mini-header and a 
packet is not known at said network node 

3. The method of claim 1 , wherein said payload por- 
tion for each packet is less than or equal to 256 
bytes in length. 

4. The method of claim 1 , wherein each of said mini- 
headers comprises a channel identifier, identifying 
payload data intended to be exchanged between 
the same source and destination on said pack t 
switched network. 

5. The method of claim 4, wherein each of said mini- 
headers further comprises an indicator of a length 
of an associated payload portion. 

6. The method of claim 4, wherein said channel iden- 
tifier is eight bits in length. 

7. The method of claim 1 , further comprising querying 
said node to assess if said node is capable of de- 
multiplexing said multiplexed packet, prior to dis- 
patching said multiplexed packet to said node. 



8. The method of claim 4, further comprising maintain- 
ing an indicator of when a mini-header including an 
already used channel identifier is processed, said 
indicator, indicative of continued network communi- 
cation between a source and destination associat- 
ed with said channel identifier. 



Claims 

1 . A method of multiplexing payload data contained in 
a plurality of packets to be passed by way of a net- 
work nod within a packet switch d data network, 
ach of said plurality of pack ts comprising a h ad- 
r for routing said ach of said plurality of packets 
on said network, said method comprising: 



50 9. The method of claim 1 , wherein said mapping token 
comprises said header for said one of said packets. 

10. A method of forming a mapping table at a network 
nod within a pack t switched network, said map- 
55 ping tabl for mapping mini-headers identifying 
multipl xed payload data from several pack ts 
within a multiplexed packet, to complete headers 
usable to transport payload on said network, said 
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method comprising: 

receiving a packet comprising: 

at least one payload data portion from one 
of said packets; 

a mini-header associated with said at least 
one payload data portion; 
a mapping token, indicative of a relation- 
ship between said mini-header and a com- 
plete header for transporting said at least 
one data portion on said network; 

forming a new entry within said table, including 
a portion of said mini-header and information 
derived from said mapping token, indicative of 
a relationship between said mini-header and 
said complete header. 

11. The method of claim 10, wherein said mini-header 
comprises a channel identifier, identifying a logical 
channel within said multiplexed packet. 

12. The method of claim 11 , wherein said channel iden- 
tifier is stored within said mapping table. 

1 3. The method of claim 1 0, wherein said network node 
comprises a router on said packet switched data 
network. 

14. The method of claim 10 wherein said mapping table 
is updated each time a mini-header including an al- 
ready defined channel identifier is received, indicat- 
ing network communication associated with said 
logical channel is active. 

15. The method of claim 14, further comprising deleting 
an entry for which a mini-header including an al- 
ready defined channel identifier is not received for 
a defined interval. 

16. A computer data signal embodied in a carrier wave 
comprising: 

at least one payload data portion from a packet 
transportable within a packet switched data 
network, said packet including a complete 
header for routing said packet on said network; 
a mini header associated with said at least one 
payload data portion; 

a mapping token, indicative of a relationship be- 
tween said mini-header and said complete 
header. 

17. The computer data signal of claim 1 6, wher in said 
mini-header is short r than said complete header. 

18. The computer data signal of claim 1 7, wherein said 



at least one payload data portion is less than or 
equal to 256 bytes in length. 

19. The computer data signal of claim 16, further com- 
5 prising: 

additional payload data portions from packets 
transportable within said packet switched data 
network; 

10 a mini-header associated with each of said ad- 

ditional payload data portions. 

20. The computer data signal of claim 17, wherein said 
mini-header comprises sixteen bits. 

15 

21 . The computer data signal of claim 1 9, wherein each 
mini-header comprises a channel identifier, identi- 
fying a logical channel within said computer data 
signal. 

20 

22. A computing apparatus interconnected with a pack- 
et switched data network, comprising computer 
readable memory storing 

25 a mapping table for mapping mini-headers 

identifying multiplexed payload data from sev- 
eral packets within a multiplexed packet to a 
complete header usable within said packet 
switched data network; 

30 computer readable instructions, adapting said 

apparatus to process multiplexed packets com- 
prising: 

one or more payload portions, formed from 

35 packets on said network; 

one or more mini-headers associated with 
a payload portion within said multiplexed 
packet and usable by said apparatus in 
conjunction with said mapping table to con- 

40 struct a packet including said associated 

payload that may be transported on said 
packet switched data network; 
at least one mapping token, usable by said 
apparatus to update said mapping table. 

45 

23. The apparatus of claim 22, wherein said computer 
readable instructions adapt said apparatus to de- 
multiplex multiplexed packets, using said mini- 
headers, said payload portions and said mapping 

so tables to construct packets transportable on said 
network and containing said payload data. 

24. A computer readable storage medium, storing corn- 
put r readable instruction that wh n loaded into a 

S5 computing device interconnected to a packet 
switch d network, adapts said computing device to 

associate with a payload portion of each one of 
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a plurality of data packets from said network, 
each comprising a header, a mini-header small- 
er than a header for said each one packet; 
include said payload portion for each one of 
said plurality of data packets and associated s 
mini-header in a multiplexed packet; 
include in said multiplexed packet a mapping 
token, establishing a relationship between a 
mini-header and one of said plurality of data 
packets, for which said relationship between a io 
mini-header and a data packet is not known at 
a network node whereat said multiplexed pack- 
et is to be demultiplexed; 



constructing a multiplexed pack t comprising 
said mapping token, said payload portion and 
said associated mini-header. 

27. A computer program element comprising computer 
program code means to make a computing appara- 
tus execute procedure to perform the method steps 
of any of claims 1 to 15, or 26. 

28. The computer program element of claim 27, embod- 
ied on a computer readable medium. 



thereby multiplexing payload data contained in said is 
plurality of data packets in a multiplexed packet to 
be passed to said network node. 



25. A computer readable memory storing computer ex- 
ecutable instructions, executable by a computing 20 
device interconnected with a packet switched net- 
work, said computer readable instructions, adapt- 
ing said computing device to: 

maintain a mapping table for mapping mini- 
headers identifying multiplexed payload data from 25 
several packets within a multiplexed packet to a 
complete header usable within said network; 
and adapting said computing device to process at 
least one multiplexed packet including: 

30 

a payload portion, formed from a packet trans- 
ported on said network; 

a mapping header associated with said payload 
portion within said multiplexed packet and us- 
able by said computing device in conjunction 35 
with said mapping table to construct a packet 
including said associated payload portion that 
may be transported on said network; 
mapping information, usable by said computing 
device to update said mapping table. 40 



26. A method of multiplexing payload data contained in 
a plurality of packets to be passed by way of a net- 
work node in a switched packet network, compris- 
ing: 45 



for each packet to be passed by way of said 
network node, searching a table with informa- 
tion in a header of said each packet for a match; 
on not finding a match for a given packet having so 
a given header, entering information from said 
given header in said table in association with 
information for a mini-header; 
creating a mapping token associating said giv- 

n h ader information with said mini-header; ss 
extracting a payload portion of said given pack- 
et, discarding said given header and associat- 
ing said mini-header with said payload portion; 
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